Our Ref.: 42390.P7948 



APPLICATION FOR UNITED STATES LETTERS PATENT 



FOR 



Method And Apparatus 
For Protected Exchange Of Status And Secret Values 
Between A Video Source Application 
And A Video Hardware Interface 



Inventor(s): Robert W. Faber 
David A. Lee 
Brendan S. Traw 
Gary L. Graunke 
Richard P. Mangold 

Prepared by: 

BLAKELY SOKOLOFF TAYLOR & 2AFMAN. LLP 
12400 Wilshire Boulevard, 7th Floor 
Los Angeles, California 90025 
(503) 684-6200 



"Express Mail" Label Numbe r EL431686001US 



Attorney Docket Ref: 42390.P7948 

Method And Apparatus For Prot ct d Exchanq Of Status And Seer t Values 
B twe n A Vid o Source Application and A Vid o Hardware Interface 

Related Application 

5 This application is a continuation-in-part application to U.S. Patent 

Applications number 09/385,590 and 09/385.592. both entitled Digital Video Content 
Transmission Ciphering and Deciphering Method and Apparatus, filed on August 29, 
1999. 

xss. 

10 BACKGROUND OF THE INVENTION 



1. Field of the Invention 
The present invention relates to the field of content protection. More 

O specifically, the present invention addresses the protection accorded to exchange of 

yj 15 status and secret values between a video source application and a video hardware 
p interface of a video source device. 

2. Background Information 

In general, entertainment, education, art, and so forth (hereinafter collectively 
20 referred to as "content") packaged in digital form offer higher audio and video quality 
than their analog counterparts. However, content producers, especially those in the 
entertainment industry, are still reluctant in totally embracing the digital form. The 
primary reason being digital contents are particularly vulnerable to pirating. As 
unlike the analog form, where some amount of quality degradation generally occurs 
25 with each copying, a pirated copy of digital content is virtually as good as the "gold 
master". As a result, much effort have been spent by the industry in developing and 
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adopting techniques to provide protection to tlie distribution and rendering of digital 
content. 

Historically, the communication interface between a video source device 
(such as a personal computer) and a video sink device (such as a monitor) is an 
analog interface. Thus, very little focus has been given to providing protection for 
the transmission between the source and sink devices. With advances in integrated 
circuit and other related technologies, a new type of digital interface between video 
source and sink devices is emerging. The availability of this type of new digital 
interface presents yet another new challenge to protecting digital video content. 
While in general, there is a large body of cipher technology known, the operating 
characteristics such as the volume of the data, its streaming nature, the bit rate and 
so forth, as well as the location of intelligence, typically in the source device and not 
the sink device, present a unique set of challenges, requiring a new and novel 
solution. Parent applications number 09/385,590 and 09/385,592 disclosed various 
protocol and cipher/deciphering techniques to protect the transmission. 

Similar protection challenges exist for exchanges of status and secret values 
between the video generating video source application and the video transmitting 
video hardware interface of the video source device. Thus, method and apparatus 
to protect these exchanges are desired. 
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SUMMARY OF THE INVENTION 

A video source application in a video source device requests from a video 
hardware interface of the video source device status with respect to a link linking the 
video source device to an external video sink device, and supplements the status 
request with a basis value to a symmetric ciphering/deciphering process. The video 
source application, upon receiving from the video hardware interface the requested 
status and a verification key, generated using a symmetric ciphering/deciphering 
process and employing the basis value, verifies the correctness of the verification 
key to determine whether to trust said provided status. 
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BRIEF DESCRIPTION OF DRAWINGS 

The present invention will be described by way of exennplary embodiments, 
but not limitations, illustrated in the accompanying drawings in which like references 
denote similar elements, and in which: 

Figure 1 illustrates an overview of the present invention in accordance with 
one embodiment; 

Figures 2a-2b illustrate a symmetric ciphering/deciphering process based 
method for the video hardware interface to provide sensitive information such as 
status and secret values to the video source application, In accordance with two 
embodiments; 

Figures 3a-3b illustrate the symmetric ciphering/deciphering process of Fig. 
2a-2b employed to facilitate provision of status and secret values from the video 
hardware interface to the video source application, in accordance with one 
embodiment each; and 

Figures 4a-4c illustrate a one way function suitable for use to practice the 
symmetric ciphering/deciphering process of Fig. 3a-3b in further detail, in 
accordance with one embodiment 
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DETAILED DESCRIPTION OF THE INVENTION 

in the following description, various aspects of the present invention will be 
described, and various details will be set forth in order to provide a thorough 
5 understanding of the present invention. However, it will be apparent to those skilled 
in the art that the present invention may be practiced with only some or all aspects of 
the present invention, and the present invention may be practiced without the specific 
details. In other instances, well known features are omitted or simplified in order not 
to obscure the present invention. 
t 10 Various operations will be described as multiple discrete steps performed in 

i! turn in a manner that is most helpful in understanding the present invention. 

However, the order of description should not be construed as to imply that these 
operations are necessarily performed in the order they are presented, or even order 

^ dependent. Lastly, repeated usage of the phrase "in one embodiment" does not 

P 

y 15 necessarily refer to the same embodiment, although it may. 



! . ; 



Referring now to Figure 1, wherein a block diagram illustrating an overview 
of the present invention, in accordance with one embodiment is shown. As 
illustrated, video source device 102 and video sink device 104 are coupled to each 

20 other via digital video link 106. Video source device 102 includes video source 
application 108 and video hardware interface 110. Video source application 108 
generates and provides video content to video hardware interface 110, which in turn 
ciphers video content and provides the video content in a ciphered form to video 
sink device 104 through digital video link 106 as disclosed in the aforementioned 

25 parent applications, thereby protecting video contents. Additionally, video source 
application 108 and video hardware interface 110 exchange various status and 
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control information, including in particular status information about the link between 
video liardware interface 110 and video sink device 104, and secret values 
employed by video hardware interface 110 to cipher video content as disclosed in 
the parent applications. In accordance with the present invention, video source 
application 108 and video hardware interface 110 are equipped to be able to jointly 
practice a symmetric ciphering/deciphering process. As a result, at least status and 
secret values may be provided from video hardware Interface 110 to video source 
application 108 in a protected manner, maintaining protection to the video content 
being distributed to video sink device 104. 

Except for the teachings of the present invention incorporated, to be 
described more fully below, video source application 108 is intended to represent a 
broad range of video source applications known in the art, while video hardware 
interface 110 is substantially constituted as disclosed in the parent applications. As 
will be readily apparent from those skilled in the art, the present invention 
advantageously allows the same hardware resources of video hardware interface 
110 to be used to protect the exchanges with video source application 108 as well 
as protecting the video content transmitted to video sink device 104. 

As disclosed in the parent applications, examples of video source device 102 
includes but not limited to computers of all sizes (from palm size device to desktop 
device, and beyond), set-up boxes, or DVD players, whereas examples of video sink 
devices include but not limited to CRT monitors, flat panel displays or television 
sets. As to digital video link 106, it may be implemented in any one of a number of 
mechanical and electrical forms, as long as they are consistent with the operating 
requirement (i.e. speed, bit rate and so forth), and a mechanism (which may be in 
hardware or through protocol) is provided to allow control information to be 
exchanged between video source and sink devices 102 and 104. 
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Before proceeding to further described the present invention, while for ease 
of understanding, video source application 108 is shown to be interacting with video 
hardware interface 110 "directly", those skilled in the art will appreciate that typically 
video hardware interface 110 has an associated driver to insulate the hardware 
specifics from the interacting software, such as video source application 108 in this 
case. Accordingly, in most embodiments, video source application 108 interacts 
with video hardware interface 110 through its associated driver. 

Figures 2a-2b illustrate two overviews of the symmetric 
ciphering/deciphering process based method for facilitating exchanges of status and 
control information between video source application 108 and video hardware 
Interface 110, in accordance with two embodiments. Fig. 2a is an embodiment 
particularly suitable for exchanges involving status and control information of short 
bit lengths, such as on/off status, whereas Fig. 2b is an embodiment particular 
suitable for exchanges involving status and control information of longer bit lengths, 
such as the secret values employed by video hardware interface 110 to cipher video 
contents. What constitutes short or longer bit length is application dependent. As 
between video hardware interface 110 and video sink device 104, video source 
application 108 and video hardware interface 110 are assumed to have each been 
provided with an array of private "cryptographic" keys and a complementary 
identifier by a certification authority. In one embodiment, each of video source 
application 108 and video hardware interface 104 is pre-provided with an array of 40 
56-bit private "cryptographic" keys by the certification authority. Cn is a 64-bit 
random number, and the keys are 56-bit long. For more information on the above 
described authentication process, see co-pending U.S. Patent Application, serial 
number 09/275,722, filed on March 24, 1999, entitled Method and Apparatus for the 
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Generation of Cryptographic Keys, having common assignee with the present 
application. 

As illustrated in Fig. 2a, whenever a need occurs for video source application 
to retrieve a status of the short bit length type, video source application 108 first 
5 generates and provides a basis value to the symmetric ciphering/deciphering 
process to sink hardware interface 110. For the illustrated embodiment, the basis 
value is a random number (Cn). Cn may be generated in any one of a number of 
techniques known in the art. Additionally, video source application 108 also 
provides a key selection value (Ck^) to video hardware interface 110. Further, for 
5 10 the illustrated embodiment, which is an embodiment where the same hardware 
2 resources of video hardware interface 1 10 are used to satisfy video source 
u application's request for status and control information of the short or long bit length 
S type, video source application 108 also provides a mode indicator (C^o^e) to video 
1^ hardware interface 110 to denote the type of status and control information being 

ri 15 requested. These parameters, C^, Ck^^, and 0^,0^^ may be provided via one or more 

UJ 

^ "packets", as well as in conjunction with other information. 

O 

B In response, video hardware interface 110 generates an authentication key 

Ku' based on its provided array of private "cryptographic" keys Dkeys and the 
selection key Ck^^ provided by video source application 108. Video hardware 

20 interface 110 then generates the verification key Kp' based on the provided basis 
value Cn, the generated authentication key K^', the status to be returned, and the 
selection key Bkg^ it was provided by video sink device 104 for use to protectively 
provide video contents in a ciphered form to video sink device 104 based on a 
symmetric cipher/deciphering process (see parent application for further detail). 

25 Upon generating Kp, for the illustrated embodiment, video hardware interface 

110 returns the requested status along with Kp'. In one embodiment, the two values 
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are concatenated together (S'), and returned at the sanne time. In alternate 
embodinnents, it may be returned separately. Additionally, for the illustrated 
embodiment, video hardware interface 110 also returns Bk^^ and Okg^ to video 
source application 108. 
5 Over on the video source application side, upon receipt of S', Bks^ and Okg^, 

video source application 108 independently generates its own copy of based on 
its array of pre-provided private "cryptographic" keys Ckeys, and Dk^^. Next, video 
source application 108 independently generates its own copy of Kp based on C^, the 
returned status, and Bk^^. Then, video source application 108 compares its 

0 10 independently generated Kp with the received Kp' to determine if it should trust the 

01 status provided (when Kp=Kp ) or distrust the status provided (when Kp=/=Kp'). 

O Referring now to Fig. 2b, in like manner, whenever a need occurs for video 

ig source application to retrieve a control information of the longer bit length type, such 
T' as the aforementioned secret value, video source application 108 also first 

2 15 generates and provides a basis value to the symmetric ciphering/deciphering 

^ process to sink hardware interface 110. Again, in one embodiment, the basis value 
~ is a random number (Cn), and it may be generated in any one of a number of 
techniques known in the art. Additionally, video source application 108 also 
provides a key selection value (Ck^J) to video hardware interface 110. Further, 
20 similar to the embodiment of Fig. 2a, where the same hardware resources of video 
hardware interface 1 10 are used to satisfy video source application's request for 
status and control information of the short or long bit length type, video source 
application 108 also provides a mode indicator {C^^) to video hardware interface 
110 to denote the type of status and control information being requested. As before, 
25 these parameters, C^, Ck^^, and Cn^ode "^lay be provided via one or more "packets", as 
well as in conjunction with other information. 
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In response, video hardware interface 110 generates an authentication key 
based on its provided array of private "cryptographic" keys Dkeys and the 
selection key Ckg^ provided by video source application 108. Video hardware 
interface 110 then generates a cryptographic key K^' using K^' and the provided 
basis value C^. 

Upon generating K^', video hardware interface 110 ciphers the requested 
control information, e.g. secret value Mq', using Kg'. Video hardware interface 110 
then returns Mq' in a ciphered fornn (M') to video source application 108. 
Additionally, for the illustrated embodiment, video hardware interface 110 also 
returns Dk^^ to video source application 108. 

Over on the video source application side, upon receipt of M' and Dkg^, video 
source application 108 independently generates its own copy of based on Ckeys 
and Dkgv. Next, video source application 108 independently generates its own copy 
of Kg based on and K^. Then, video source application 108 deciphers M', 
recovering Mq' using K^. 

Figures 3a-3b illustrate the symmetric ciphering/deciphering 
processes of Fig.2a-2b in further detail, in accordance with one embodiment each. 
As illustrated in Fig. 3a, for the exchange of status and control information of short 
bit length, video hardware interface 110 first generates the authentication key K^' by 
summing its pre-provided private "cryptographic" keys Dkeys over the provided 
selection key Ckg^ from video source application 108. Upon generation of the 
authentication key K^', video hardware interface 110 generates a first intermediate 
key K/, ciphering the least significant 40 bits (LSB40) of the provided basis value 
by applying a one way function to it, using K^'. For the illustrated embodiment, the 
same one way function is used for the exchange of status and control information of 
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both short and longer bit length type. The one way function is applied in a first 
nnode, also referred to as the A-mode, in accordance with the value of C^ode- Next, 
video hardware interface 110 generates a second intermediate key K2' by applying 
the same one way function (under the same mode) to the selection key BK^^ 
5 provided by video sink device 104, using K/. Finally, video hardware interface 110 
generates the verification key Kp' by applying the same one way function (under the 
same mode) to the status concatenated with most significant 24 bits (MSB24) of the 
provided basis value C^, using Kg'. 

Over on the video source application side, upon receipt of S', Okg^, and BK^^, 

S 10 video source application 108 first independently generates its own copy of the 
authentication key K^ by summing its selection keys Ckeys over Okg^. Upon 

□ generation of the authentication key K^^, video source application 108 independently 

m generates its own copy of the first intermediate key by applying a similar one way 

□ 

5 function to the least significant 40 bits (LSB40) of the basis value provided to 

LJ 

y 15 video hardware interface 110, using K^j. Video source application 108 also uses the 
2 same one way function to facilitate the exchange of status and control information of 
S both short and longer bit length type. Thus, the common one way function is 
applied in the earlier described first mode, also referred to as the A-mode, in 
accordance with the value of C^^^. Next, video source application 108 
20 independently generates its own copy of the second intermediate key Kg by applying 
the same one way function (under the same mode) to the selection key BKg^, using 
K^. Finally, video source application 108 independently generates its own copy of Kp 
by applying the same one way function (under the same mode) to the status 
concatenated with the most significant 24 bits (MSB24) of the basis value Cf,, using 
25 Kg. 
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Fig. 3b illustrates the embodiment for handling the exchange of status and 
control information of longer bit length, video hardware interface 110 first generates 
the authentication key K^' by summing Its selected one of the pre-provided private 
"cryptographic" keys over the provided selection key from video source application 
108. Upon generation of the authentication key K^^', video hardware interface 110 
generates another intermediate key K/ by applying a one way function to the least 
significant 40 bits (LSB40) of the provided basis value C^, using K^'. For the 
illustrated embodiment, the same one way function is used for the exchange of 
status and control information of both short and longer bit length type. The one way 
function is applied in a second mode, also referred to as the B-mode, in accordance 
with the value of Cf^ode- Next, video hardware interface 110 generates Kg, the 
ciphering key, by applying the same one way function (under the same mode) to the 
most significant 24 bits (MSB24) of the provided basis value C^, using K/. 

Over on the video source application side, upon receipt of M' and Okg^, video 
source application 108 first independently generates its own copy of the 
authentication key K^, by summing its array of private "cryptographic" keys Ckeys 
over Dkg^. Upon generation of the authentication key K^, video source application 
108 independently generates its own copy of intermediate key K4 by applying a 
similar one way function to the least significant 40 bits (LSB40) of the basis value 
Cn, using K^^. Video source application 108 also uses the same one way function to 
facilitate the exchange of status and control information of both short and longer bit 
length type. Thus, the common one way function is applied in the earlier described 
second mode, also referred to as the B-mode, in accordance with the value of C^^de- 
Next, video source application 108 independently generates its own copy of Kp, the 
deciphering key, by applying the same one way function (under the same mode) to 
the most significant 24 bits (MSB24) of the basis value C^, using Ki. 
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In one ennbodiment, and K4 are generated only by video source application 
108, once per "session", using highly protected Ckeys, and stored in the application 
for later use for the rennainder of the session. In other words, connpromise of K1 or 
K4 allows "attack" for only one session (connpromise of Ckeys would allow "attack" 
for unlimited number of sessions). This approach has the following advantages. 
Since Dk^^ is a constant, video source application 108 can fix the least significant 40 
bits of Cn, and change only the most significant 24 bits of for different status and 
information requests, thereby allowing video source application 108 to rerun the 
protocol for different requests at the computation of and K4 and speed up the 
transfer of these information. 

Figures 4a^c illustrate a one-way function suitable for use to practice the 
symmetric ciphering/deciphering process of Fig. 3a-3b, in accordance with one 
embodiment. As illustrated in Fig. 4a, the one way function 800 includes a number 
of linear feedback shift registers (LFSRs) 802 and combiner function 804, coupled to 
each other as shown. LFSRs 802 and combiner function 804 are collectively 
initialized with the appropriate keys and data values, depending the mode of 
operation C^o^^. During operation, the values are successively shifted through 
LFSRs 802. Selective outputs are taken from LFSRs 802, and combiner function 
804 is used to combine the selective outputs to generate the desired outputs. 

In one embodiment, four LFSRs of different lengths are employed. Three 
sets of outputs are taken from the four LFSRs. The polynomials represented by the 
LFSR and the bit positions of the three sets of LFSR outputs are given by the table 
to follow: 



Faber et al. - 

M&A For Protected Exchange 



13 



Express No: EL43i6a600ius 
ATA/mjt 



Attorney Docket Ref: 42390.P7948 







Combining Function 


1 r ^ n 

LFSR 


Polynomial 




Taps 








0 


1 




o 
o 


A+A+A+X + 


8 


17 


26 












2 


X^^ + X^^ + x^^ + x^^ + 


8 


16 


25 




x^^ + x« + 1 








1 




7 


15 


23 




+ X^ + 1 








0 


x^' + x^° + x^' + x'^ + )^ + 


7 


14 


22 




/ + 1 









The initialization of the LFSRs and the combiner function, more specifically, 
the shuffling network of the combiner function, is in accordance with the following 
table. 





Bit Field 


One Way- A 
Initial Value 


One Way-B 
Initial Value 


LFSR3 


[26:22] 


Data [39:35] 


Data[34:30] 




[21] 


inverse of LFSR3 
initialization bit [9] 


inverse of LFSR3 
initialization bit [9] 




[20:14] 


Data[34:28] 


Data[29:23] 




[13:0] 


Kev[55:421 


Key[48:35] 


LFSR2 


[25:22] 


Data[27:24] 


Data[22:19] 




[21] 


inverse of LFSR2 
initialization bit [8] 


inverse of LFSR2 
initialization bit [8] 




[20:14] 


Data[23:17] 


data[18:12] 




[13:0] 


Key[41:28] 


Key[34:21] 


LFSR1 


[23:19] 


Data[16:12] 


Data[11:7] 
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[18] 


inverse of LFSR1 
initialization bit [5] 


inverse of LFSR1 
initialization bit [5] 




[17:141 


Data[1 1 :81 


Data[6:3] 




[13:01 


Key[27:141 


Key[20:7] 


LFSRO 


[22:201 


Data[7:5] 


Data[2:0] 




[19] 


inverse of LFSRO 
initialization bit [10] 


inverse of LFSRO 
initialization bit [10] 




[18:141 


Data[4:01 


Data[39:351 




[13:7] 


Key[13:7] 


Key[6:01 




[6:0] 


Key[6:01 


Key[55:49] 


Shuffle 


Register A 


0 


0 


Network 


Register B 


1 


1 



Data are LSB40(C,), BK^, and MSB24(CJ, whereas Keys are K„ K^, K2 and 

The combined result is generated from the third set of LFSR outputs, using 
the first and second set of LFSR outputs as data and control inputs respectively to 
combiner function 804. The third set of LFSR outputs are combined into a single bit. 

Fig. 4b illustrates combiner function 804 in further detail, in accordance with 
one embodiment. As illustrated, combiner function 804 includes shuffle network 806 
and XOR 808a-808b, serially coupled to each other and LFSRs 802 as shown. For 
the illustrated embodiment, shuffle network 806 includes four binary shuffle units 
810a-810d serially coupled to each other, with first and last binary shuffle units 810a 
and 81 Od coupled to XOR 808a and 808b respectively. XOR 808a takes the first 
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group of LFSR outputs and combined them as a single bit input for shuffle network 
806. Binary shuffle units 810a-810d serially propagate and shuffle the output of 
XOR 808a. The second group of LFSR outputs are used to control the shuffling at 
corresponding ones of binary shuffle units 810a-810d. XOR 808b combines the 
third set of LFSR outputs with the output of last binary shuffle unit 81 Od. 

Fig. 4c illustrates one binary shuffle unit 810* (where * is one of a-d) in 
further detail, in accordance with one embodimenL Each binary shuffle unit 810* 
includes two flip-flops 812a and 812b, and a number of selectors 814a-814c, 
coupled to each other as shown. Flip-flops 812a and 812b are used to store two 
state values (A, B). Each selector 814a. 814b or 814c receives a corresponding 
one of the second group of LFSR outputs as its control signal. Selector 814a-814b 
also each receives the output of XOR 808a or an immediately preceding binary 
shuffle unit 810* as input. Selector 814a-814b are coupled to flip-flops 812a-812b to 
output one of the two stored state values and to shuffle as well as modify the stored 
values in accordance with the state of the select signal. More specifically, for the 
illustrated embodiment, if the stored state values are (A, B), and the input and select 
values are (D, S), binary shuffle unit 810* outputs A, and stores (B, D) if the value of 
S is "0". Binary shuffle unit 810* outputs B, and stores (D, A) if the value of S is "1". 

In one embodiment, once the data values are loaded into the registers and 
the shuffle networks, the one-way function is clocked for 32 clocks to mix the data 
and key bits. During this warm up period, the 32 output bits are discarded. As a 
result, the initial output stream is a non-linear function of many key and data bits. In 
alternate embodiments, depending on the desired robustness level, the present 
invention may be practiced with shorter or longer warm up period. 
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# 



Those skilled in the art will appreciate that this one way function substantially 
parallel one embodiment of the one way function disclosed in the parent 
applications for the cipher employed by video hardware interface 110 to cipher video 
content to be transmitted to video sink device 104. Accordingly, video hardware 
interface 110 may employ the same one way function to facilitate exchange of 
status and control information with video source application 108 in a protected 
manner, as well as to cipher video content for video sink device 104. 

Accordingly, a novel method and apparatus for ciphering and deciphering 
video content to protect the video content from unauthorized copying during 
transmission has been described. 

Epilogue 

From the foregoing description, those skilled in the art will recognize that 
many other variations of the present invention are possible. Thus, the present 
invention is not limited by the details described, instead, the present invention can 
be practiced with modifications and alterations within the spirit and scope of the 
appended claims. 
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